This invention relates to a technology of producing duplicate requests from a received request, and executing the duplicate requests on a plurality of computers.
As the Internet technology has matured recently, business systems have been widely made into Web applications. For Web application servers (hereinafter, referred to as AP servers) providing basis for executing user application programs (hereinafter, referred to as user AP's) realized by the Web applications, high performance and reliability are requested.
Presently, as a technology for enhancing performance of a system, there is proposed a system building method employing a load balancer. In the system employing the load balancer, a plurality of application servers which can execute the same applications are provided, and receive processing requests via the load balancer.
The load balancer selects, based on a load state, an application server which processes the request. By preventing a load from concentrating on a certain application server, response performance of the system is increased.
The load balancer usually monitors failure information of the application servers provided on a subsequent stage, and selects application servers while avoiding failed application servers. By redundancy realized by this hot standby, it is possible to increase the availability of the service.
However, in the redundancy realized by the hot standby, when an application server fails during the processing of a request, the request under processing receives an error or no response. The conventional load balancer cannot recover the generated error.
JP 2004-030204 A discloses, in order to solve this problem, a technology of dividing servers into a plurality of groups of a plurality of servers provided on a subsequent stage of a load balancer, producing, from a received request, duplicate requests on a load balancer, and causing the plurality of servers to process the duplicate requests in parallel.
In the technology, in order to cause the servers to process the duplicate requests in parallel, the servers are first caused to process the request as “tentative execution”. A server from which the load balancer receives a response from the “tentative execution” for the first time carries out “real execution”, and finally responds. The other servers carry out “execution cancellation”. A series of technologies including the “tentative execution”, the “real execution”, and the “execution cancellation” are generally referred to as transaction processing, and are mounted on a database server and the like in order to maintain consistency in a system.
According to the technology disclosed in JP 2004-030204 A, the processing carried out by the servers provided on the subsequent stage of the load balancer is made into redundant processing, and, even when one server fails, other servers are carrying out response processing to the same request, and hence the system as a whole can continue the processing. In this way, it is possible to realize a system having stable response performance without exerting influence of a failure of a server inside the system on the outside of the system.
A description will also be given of a technology for realizing a redundant configuration. As the performance of servers has recently been increased, a virtual computer technology has been remarkably developed. Consequently, it is possible to run a plurality of virtual computers on the same physical computer.
A virtual computer of so-called hypervisor type can, without necessity of an OS (host OS) for operating virtual computers, provide a function for sharing a resource layer of the physical computer, and can operate a plurality of different OS'es in parallel.
When a system redundantly configured is realized, the method of using a plurality of virtual computers is excellent in cost such as management and operation costs, space saving, and low power consumption compared with a method of using a plurality of physical computers.
For a business system realized by a Web application, there is required a mechanism of maintaining, on a server, session information for executing a single task processing as a flow of a plurality of requests and responses and realizing an application including a screen transition. As the mechanism for maintaining the session information on the server, the sticky function is generally used.
In the sticky function, a load balancer analyzes session information, and, when a certain session ID is transmitted, and thus, a processing server is to be selected, searches for a record of a server which has processed the same session ID, thereby always selecting the same server for this session ID.
However, when the sticky function is used, the load balancer cannot exhibit the load balancing function, and the optimum performance is not realized in the system as a whole.
Moreover, when a session is fixed to only a single server which can process a necessary request, the dependency of the request on the server increases. As a result, the continuity of the system cannot be guaranteed upon a failure of a single server machine. This still holds true for the technology disclosed in JP 2004-030204 A.
As a solution for this problem, a session management method employing a shared external database machine and the like is known. The session information is recorded on an external database different from the server which processes a request, and is shared among all the servers.
The method of managing the session information on the external database is inferior to the sticky function in performance. However, generally, high performance is realized at low cost as the performance of hardware device increases. When high reliability is required, it is desirable to uniformly share a session among servers.
A description will now be given of a problem of a session collision which occurs when, from a request, duplicate requests are produced. Usually, session information is uniquely managed according to an identifier (ID) inside a system, and hence requests having the same session ID are not processed in parallel. Therefore, for the same session ID, a plurality of requests for session registration are not generated.
However, when duplicate requests are produced from a request, there may be a case in which a plurality of pieces of “session information for the same request” are registered from a plurality of application servers to a client computer, and can be referred to. When the plurality of pieces of session information are registered, and contents thereof are different, it is necessary to properly select information to be referred to. When the selection fails, inconsistency may arise in the system. This problem is referred to as “problem of session collision”.
The problem of the session collision is caused by a fact that “when the same user application program receives the same request, it is not guaranteed that the same session information is produced”. As a typical example thereof, a description will now be given of a lottery system.
In the lottery system, according to a random number generated by an application, a “win” or a “blank” is drawn. Therefore, when the same request is processed on a plurality of application servers, it is not guaranteed that all results of the processing are the same. In a case of “win” and in a case of “blank”, different pieces of session information are generally produced with a high probability.
As another example, a description will now be given of a ticket reservation system including processing for determining a deadline. In the processing for determining a deadline in the ticket reservation system, when “the present time of an application server” is used as the reference of the deadline, it is not guaranteed that the time referred to by determination processing is always the same for the respective duplicate requests. As a result, the processing of determining “whether the deadline has been reached or not” depends on the application server, and the session information produced by the respective application servers may vary.
According to the technology disclosed in JP 2004-030204 A, when duplicate requests are produced from a request, the sticky function can be realized. This is carried out in consideration of application to the session management, but the session management using the sticky function cannot solve the problem of the session collision.
Specifically, as a method for realizing the sticky function, when the “execution cancellation” is carried out, the session information is not deleted, but is held on the server. Then, when a request requiring this session information is received again, the request is directed to the same group of servers, thereby reusing the session information. In this case, if the produced session information varies depending on the servers, different pieces of information are managed by a pair of the servers, resulting in inconsistency in the system.